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Introduction 



1.1 Purpose 

This document is intended to expand the DOVE Program Diagnostic Goals into a cohesive 
diagnostic strategy that defines a set of diagnostic design guidelines and detailed fault 
isolation strategies to the FRU level. 

1.2 Scope 

This strategy is applicable for both the DAISY and DAYBREAK configurations of the 
DOVE workstation. It documents an engineering- strategy for implementing diagnostic 
capabilities that enables all published Dove Program Diagnostic Goals (see Reference 
Documents, Section 1.3) to be met, except as noted. 

This document is the last document in a series to be published by the DOVE Diagnostic 
Team over a period spanning several months. [See DOVE Diagnostic Development Plan 
Rev. 01 published 4/13/84 by M. Dugan.] Additional diagnostic documentation will be 
included in subsequent design documents and manuals. 

1.3 Reference documents 

DAISY SRS - Version 07, 10/83 

DAWN (Daybreak) SRS - Version 07, 10/83 

DOVE Service Strategy - Revision C, 4/84. 

DOVE Diagnostic Development Plan Revision 01, 04/13/84 

Memo: Frederick to Printis - DAISY Program Review, 2/3/84 

DAISY Diagnostic Package Version 01, 3/2/84 

DAISY Diagnostic Package Response by A. Stafford, 4/02/84 

DOVE Diagnostic Goals Document Version 05, 05/18/84 
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Introduction 



1.4 Contributors 

R.Auld OSD/Service 

M. Dugan XSG 

C. Fay OSD/SDD 

T. Frederick OSD/Service 

R. Knauss ED 

R. Matsuda ED 

R.Ogus OSD/SDD 

A. Stafford OSD/Service 

P. Timm OSD/SDD 

1.5 Acronym definition 

SRS System Requirements Specification 
PSR Product Support Representative 
FRU Field Replaceable Unit 

CRU Customer Replaceable Unit (See detailed definition under 1.7) 
PWBA Printed Wire Board Assembly 
lOP Input Output Processor PWBA 
UMC Unit Manufacturing Cost 

PC Personal Computer - Refers to IBM Guidelines PC Emulation 
FIP Field Isolation Procedures 
LED Light Emitting Diode 

1.6 Diagnostics definition 

Diagnostics is defined as those workstation features, implemented by either hardware or 
software, whose purpose is to identify a hardware malfunction and aid the service person 
in isolating the problem to a field replaceable assembly. It also includes all software 
utilized in verifying that the machine has been returned to operating specifications. 

1.7 Other definitions 

PSR The DOVE PSR is defined by the Service Strategy as: An entry-level 

employee who is a graduate of a technical/vocational school or a two- 
year college. He has little industrial experience, is just entering the 
labor force, has strong customer relations orientation, and has 
sufficient knowledge/skills to pass hiring test battery. 
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DAYBREAK LSI version of the DOVE workstation which utilizes a 2901 bit slice 

Mesa processor and gate arrays utilized for display and memory 
controllers. 

DAISY Custom VLSI version of the DOVE workstation which utilizes the A 

& S chips to implement the Mesa processor, display controller, and 
memory controller. 

CRU The DOVE CRUs are defined as a subset of the DOVE FRUs and are 

replaceable by the DOVE user level customer. CRUs will include all 
system components which the user is expected to install. 

Present DOVE CRUs are defined as: Display module and cables, 
keyboard and cable, mouse and cable. 

Failures Failures of DOVE system components referred to in this document 

are defined as hardware related failures only. 
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2.1 Diagnostic users 



The following paragraphs identify the users of DOVE diagnostics, and define each user's 
level of diagnostic function. 

Customer Personnel 



Customer User 



A workstation operator who may have little or no prior experience 
with workstations. May be totally unskilled or unwilling to 
perform system repair and/or maintenance (lowest technical skill 
level). May replace workstation components at the CRU level. 

Diagnostic function: to identify and isolate system failures to the 
local workstation or other network component for the purpose of 
customer user maintenance, system administrator support, or 
service notification. 



Customer 
User Support 



A customer supplied PSR who is experienced and has been defined 
by the customer as their support person. Can follow step-by-step 
procedures and has approximately the raw skill/capability of a 
Xerox PSR. May replace workstation components at the FRU 
level. 



Customer 

System 
Administrator 



Diagnostic function: to isolate/repair hardware failures at the 
FRU level and verify repair. 

A designated customer user assigned to administer the network 
services and to assist in isolating the local workstation or other 
network components for the purpose of service notification. 

Diagnostic function: to identify and isolate hardware failures to 
the local workstation or other network components for the purpose 
of customer user maintenance, systems analyst support, or service 
notification. Also isolates and identifies hardware/software 
interactive problems and network citizenship problems. 



Xerox Private Data 



5 



2 



DOVE diagnostic elements 



Xerox Personnel 



Product Support 
Representative 



Customer Service 
Representative 



Region Engineering 
Specialist 



NS/Consultant 
NS/Engineer 



Network Support 
Center 



The DOVE PSR is defined by the Service Strategy as an entry- 
level employee who is a graduate of a technical/vocational school 
or a two-year college. The PSR has little industrial experience, is 
just entering the labor force, has strong customer relations 
orientation, and has sufficient knowledge/skills to pass hiring test 
battery. May replace workstation components at the FRU level. 

Diagnostic function: to isolate/repair hardware failures and verify 
repair. 

The DOVE CSR is defined by the Service Strategy as a senior 
technical specialist who is a graduate of a technical/vocational 
Representative:school or a two-year college. The CSR has 
experience with network systems and OS/IP products. 

Diagnostic function: to isolate/repair hardware failures and verify 
repair. To provide first level support to the PSR with more in- 
depth, creative diagnostic skills. 

The RES is defined by the Service Strategy as a senior technical 
specialist who is a graduate of a vocational school or two-year 
college. The RES has experience with network systems, office 
systems, information processing products, and extensive CSR/PSR 
support and product suppfort. 

Diagnostic function: to provide telephone and on-site technical 
support beyond the district for current products. Responsible for 
improvement and upgrade of product knowledge and product 
performance. Provides communication link between Field 
Engineering/Product Support in headquarters. Provides major 
account support through the CSR/PSR. Provides new product 
support. 

The NSC/NSE is defined by the Service Strategy as a senior 
technical specialist who is a graduate of a technical/vocational 
school or two-year college. The NSC/NSE has experience with 
network systems, office systems, system software, network 
integration, and network citizenship. 

Diagnostic function: to provide universal second level support for 
all hardware failures, hardware/software interactive problems and 
network citizenship problems. 

The NSC is staffed and equipped to provide detailed diagnostic 
recommendations via telephone. 

Diagnostic function: to provide second level telephone support to 
the PSR/CSR/RES/NSC/NSE with more in-depth, cumulative, 
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expert diagnostic skills for all hardware failures, hardware/ 
software interactive problems, and network citizenship problems. 

Mfg. Technician A trained, skilled manufacturing technician. 

Diagnostic function: to test and insure the compatibility and 
quality of components, subassemblies, and equipment mainframes 
in the areas of final assembly, PWA test, and PWA quality 
assurance. 

System Analyst The System Analyst is defined by the Service Strategy as a 

marketing support person with a background in software/ 
hardware support and user applications maintenance. 

Diagnostic function: to isolate and identify hardware/software 
interactive problems and network citizenship problems for the 
purpose of verifying the integrity of the network hardware prior to 
setting up or modifying the software applications. 
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The following table identifies the users and types of diagnostic packages, and indicates the 
general usage patterns for troubleshooting, verification of processor hardware operation, 
and interactive testing of peripheral operation. 



Table 2.1 Diagnostic levels of access 
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1 This table is intended only to identify most frequent use and does not preclude use by any 
user of any diagnostic package. 

2 Includes all previous diagnostic packages. 

3 Preboot and Short Boot Diagnostics shall run automatically at power on. Full Boot will run 
at power on as determined by the customer-selected option; all others at user option. 

* Not planned for implementation.- sf - y * ' 



8 



Xerox Private Data 



DOVE Program Diagnostic Strategy - Version 5.0 



2 



2.2 Diagnostic operational modes 



2.2.1 Activity 

Manual Diagnostics 



Interactive Diagnostics 



Automatic Diagnostics 



2.2.2 Location 



Local Diagnostics 



Remote Diagnostics 



are those documented procedures that require no software 
involvement. These procedures are documented in the service 
manual (FIPs). 

Examples: Verification of Power Normal LED indication, 
power supply verification via test points, 
verification of connector pin condition, etc . 

are those diagnostics that require user interaction during the 
checkout and verification of the subassembly under test. 

Examples: Verification of proper display pattern' during 
display testing section of boot diagnostics, 
verification of proper key indication during 
keyboard testing, etc. 

are those diagnostics implemented in software that require no 
user intervention to answer questions or provide direction once 
the test is underway. 

Examples: Memory tests, processor verification, rigid disk 
verification. 



are those diagnostics that execute within a workstation and are 
initiated/interrogated from the user interface of the workstation 
under test. All dlag, ' uu3liLJ i tfLiiid lu in th i e diafeiiujlit uUuliLg y 
do 8 wmont are aoauumd tu be lutal diagiiubU e s . 

are those diagnostics that execute within a workstation but are 
initiated/interrogated from a remote machine or workstation 
user interface. IDluj i nujtjk dL i Llopmeiit luoourooc will not qU q w 
gjtltU j ltJ djitgnffifftiae to bo imp l omantpH on DOV E. 



2.3 Diagnostic user interfaces 

• Check charts 

• Power Normal indicator 

• LED status indicators 

• Cursor 

• Speaker 

• Optional maintenance panel 

• Bitmap display 
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2.3.1 Check charts 

Check charts are a part of the PSR documentation. They guide the PSR step by step in 
further isolating a hardware problem. They are used where hardware and software 
interfaces are inadequate or impractical. An example might be a DC power check chart. 

2.3.2 Power Normal indicator 

The Power Normal indicator indicates that DC power is ok. (Ref. Power Supply 
Specification 156P028XX.) 

2.3.3 LED status indicators 

There will be three LEDs located in the system unit, visible to the user. These will be used 
with Preboot Diagnostics to identify a failing FRU. 

2.3.4 Cursor 

The cursor displays a number or sets of numbers. These numbers are to be used in 
conjunction with check charts. The meaning of these numbers depends on the software 
which is run at the time the numbers are displayed. 

Examples of the meanings of the numbers: error codes pointing to the FRU list 

expected/observed data 
expecte'd/observed status 
operating software error code pointing to the 
user action required 

2.3.5 Speaker ' 

The speaker will be used to identify success and error conditions when the use of the 
bitmap display cursor cannot be assumed to be reliable. The success and error conditions 
are differentiated by tone frequency. 

2.3.6 Optional maintenance panel 

The optional maintenance panel will be used for Manufacturing and Field Service to 
provide diagnostic test numbers and error data above and beyond the cursor. The optional 
maintenance panel is an external device that connects to the machine through an adaptor 
to the keyboard connector at the system unit. It will have an LED or LCD display capable 
of displaying four or more digits, similar to the Dandelion maintenance panel. 

2.3.7 Bitmap display 

The bitmap display will be used whenever the hardware required to run it has been 
thoroughly verified. Barring memory size restrictions, it will be used to display: 

• system configuration 

• menu selections 

• messages 

• prompts 



10 



Xerox Private Data 



DOVE Program Diagnostic Strategy - Version 5.0 



2 



• help text 

• test names 

• subtest names 

• error data 

• FRU data 

2.4 Diagnostic packages 

• Manual Procedures 

• Preboot 

• Boot 

• Offline 

• Online 

• Operating System Diagnostics 

• Acceptance Test Procedures 

• Utilities 

• Remote 

2.4.1 Manual Procedures 

The Manual Procedures consist of check charts and hardware adjustments. Both check 
charts and hardware adjustments will be supported by the diagnostic software to the 
extent possible. They will be incorporated into the User's Manual and the PSR Manual. 
Manual check charts and hardware adjustments will be provided by Field Service with 
inputs from the diagnostic group and Engineering. " 

Examples of check charts and adjustment procedures: 

• AC power check 

• DC power check 

• Preboot check chart 

• Boot check chart 

• bitmap display adjustment procedure 

• character printer adjustment procedures 

2.4.2 Preboot Diagnostics 

The purpose of Preboot Diagnostics is to verify sufficient hardware to load and run Boot 
software and to identify detected hardware errors. The Preboot Diagnostics reside in the 
lOP EPROM. 

Preboot Diagnostics are written in 80186 assembly language. They use the status LEDs, 
the optional maintenance panel, the speaker, the cursor, and check charts for user 
interface. Preboot Diagnostics operate in the automatic mode. They are initiated any time 
the system is powered up or when the SYSTEM RESET switch is pressed (see Figure 2.1). 
Preboot Diagnostics take no more than ten seconds to run. 
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Preboot Diagnostics consist of: 



• lOP RAM verification 

• keyboard UART timer verification 

• interrupt controller verification 

• keyboard turnaround test 

• mouse coordinates test 

• 80186 timer 2 verification 

• lOP EPROM verification 

• • configuration EEPROM verification 

• memory controUer/IOP interface verification 

• display cursor verification 



Power On 



SYSTEM RESET 
switch 



OR OR 



PREBOOT 
Diagnostics — 



Boot device 
selection 



Figure 2.1 Preboot Diagnostics 

2.4.3 Boot Diagnostics 

The purpose of the Boot Diagnostics is to verify the hardware required to load and run 
Mesa software, to verify lOP hardware not accessible to the Mesa software, and to isolate 
and identify detected hardware errors. The Boot Diagnostics reside on any of the boot 
devices. Short Boot Diagnostics shall take no longer than ninety seconds for the minimum 
configuration plus 15 seconds for each additional 512 kbytes of memory. The full Boot 
Diagnostics shall take no longer than eight minutes for the minimum configuration plus 3 
minutes for each additional 512 kbytes of memory. 

The Boot Diagnostics provide the user with the option to run some of the tests for a desired 
number of passes to identify intermittent problems. 

The Boot Diagnostics are written in 80186 assembly language and in Mesa processor 
microcode. These diagnostics use the cursor, the optional maintenance panel, the speaker, 
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and check charts for the user interface. They normally operate in automatic mode and can 
also be used in interactive mode for circuit board repair. 

The Boot Diagnostics can be initiated in three ways: 

1. If the system configuration has the "Always run Boot Diagnostics" bit set, then a short 
version of the Boot Diagnostics is run automatically immediately after a Boot file has 
been selected. 

Note: If the system configuration has the "Always run Boot Diagnostics" bit reset, no 
Boot Diagnostics are executed. 

2. If the diagnostic boot file is selected, the full version of the Boot Diagnostics is run . 

3. If the boot device is selected using the keyboard (special diagnostic boot), the full 
version of the Boot Diagnostics is run (see Figure 2.2). 

Note: There is an optional boot device selection available in Preboot. This boot device 
selection uses the keyboard rather than the boot icons to select the boot device, and 
automatically loads the Boot Diagnostics. 

Boot Diagnostics consist of: 

• control store verification 

• memory controller verification 

• main memory verification 

• Mesa processor verification 

• rigid disk memory addressing verification 

• rigid disk FIFO verification 

• Ethernet memory addressing verification 

• keyboard UART timer verification 

• interrupt controller verification 

• arbiter verification 

• host ID Prom verification 

• PC Emulation option verification 

• display test patterns (while running the Display memory test) 
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DOVE diagnostic elements 



Mouse 




Keyboard ( = Diagnostic boot) 



Boot file 
selection 




Read 

System Config. 



Load 
software 
from boot 
device 



Yes 



Run Full 

Boot 
Diagnostics 




Run Short 

Boot 
Diagnostics 




Figure 2.2 Boot Diagnostics 



2.4.4. Offline Diagnostics 

The purpose of the Offline Diagnostics is to verify the peripheral hardware and to isolate 
and identify peripheral detected hardware errors. The Offline Diagnostics take control of 
the entire work station using UtilityPilot for an operating system. The Offline Diagnostics 
must be booted from one of the boot devices. 
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The Offline Diagnostics provide the user with the option to run some of the tests for a 
desired number of passes to identify intermittent problems. 

The Offline Diagnostics are mostly written in Mesa and some 80186 assembly language. 
They use the bitmap display for user interface. Offline Diagnostics operate both in the 
automatic and interactive modes. They are always initiated in the interactive mode. They 
start by displaying the system configuration and request the operator to validate it. After 
the configuration has been validated the operator is presented with a menu to run all of 
the Peripheral Diagnostics automatically or to select an individual Peripheral Diagnostic. 
Offline Diagnostics consist of tests for: 

• rigid disk 

• Ethernet 

• floppy disk 

• RS-232-C 

• keyboard, mouse, and speaker 

• bitmap display 

• character printer 

• configuration EE prom verification (validity checks) 



Load 
Offline 
Diagnostics 



Run 
Offline 
Diagnostics 



Reboot 
System 



Figure 2.3 Offline Diagnostics 



2.4.5 Online Diagnostics 



The purpose of the Online Diagnostics is to verify the peripheral hardware and to isolate 
and identify peripheral detected hardware errors. The Online Diagnostics are run like any 
other application on the basic workstation. They are written in Mesa and use the bitmap 
display for user interface. The Online Diagnostics are run only when the user selects 
them. They operate strictly in the interactive mode (see Figure 2.4). 

Online Diagnostics consist of tests for: 

• Ethernet 

• floppy disk 

• RS-232-C 

• keyboard, mouse, and speaker 

• bitmap display 
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DOVE diagnostic elements 



• character printer 

• PC emulation 




If Basic Workstation Software 



Yes 



Yes 



Run 
Online 
Diagnostics 




Figure 2.4 Online Diagnostics 



Note: The major differences between the Offline and the Online Diagnostics are: 



Boot Diagnostics are always executed before running the Offline Diagnostics. 



The Offline Diagnostics isolate toJt^««ii«r FRU ^euuiit than the Or^line Diagnostics. 



isolate to nwiMniiifiir p tiUmemrm tnan tne uni: 
The Offline Diagnostics make use of the diagnostic turnaround plugs.' 



2.4.6 Operating System Error Logging 



The Operating System Error Logging consists of two sections, Error Logging and Error 
Log Analysis. 
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Error Logging: 

Error Logging logs all encountered 10 device errors while the Operating System is 
running. It is imbedded in the Pilot Operating System. The errors are logged in two places: 

• on the system where the errors occur 

• on a designated remote file server 



Error Log Analysis: 

The purpose of Error Log Analysis is to analyze and summarize the Operating System 10 
Device errors into real and potential problems. Error Log Analysis does not identify a 
FRU list; it depends on the PSR to run the appropriate diagnostic for the FRU list. 

Error Log Analysis can be invoked in several ways: it is invoked automatically by the 
Offline Diagnostics when a service call is required (TBD); it is also invoked when the PSR 
or a customer support person requests to run Error Analysis (special password required). 

The Operating System Error Logging is written in Mesa. It uses the bitmap display for the 
user interface. 

Note: Operating System Diagnostics represent a long-term development project. They will 
be worked on only after more fundamental diagnostics such as Preboot, Boot, Offline, and 
Online are in place. As a result, they are not planned for DAYBREAK or DAISY IMO. 




If Pilot Software 



Pilot Software 




Log 
Error 



Run Error 
Analysis 



Figure 2.5 Operating System Error Logging 
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2.4.7 Acceptance Test Procedures 

The purpose of the Acceptance Test Procedures is to test a number of machines 
simultaneously for an extended period of time with minimum user intervention. They will 
primarily be used in manufacturing. 



The Acceptance Test Procedures are entirely written in Mesa and use the bitmap display 
for the user interface. They operate in the automatic mode. 

Acceptance Test Procedures consist of: 

• running Boot Diagnostics 

• running fttpisk formatter • 

• running Bjf-Disk volume initializer 

• extended burn-in which consists of: 

- rigid disk storage exerciser 

- floppy exerciser 

- Ethernet Echo Test 



Utilities are not diagnostics. They are mentioned here because some utilities are either 
very closely related to diagnostics or require diagnostics to be run before the utility is 
invoked. 

The Utilities are written in Mesa. They use the bitmap display for the user interface and 
operate strictly in the interactive mode. 

Examples of some of the Utilities: 

• format rigid disk 

• physical volume scavenger 

• format floppy disk 

• copy floppy disk 

• clean floppy heads 

• set system configuration \ 



Remote Diagnostics consist of software which alli^ws controlling the execution of Offline 
Diagnostics from a remote workstation. •*Jkvw-(LKW IL / ^ i jTT fc^^ 



Note: Remote Diagnostics is a new capability not previously provided on the Dandelion. It 
is an attractive, useful, but non-essential capability. Hence it is not required for 
DAYBREAK or DAISY IMO. More fundamental diagnostics such as Preboot, Boot, 
Offline, and Online will take precedence in the implementation plan. 

Remote executable diagnostics are: 

• Offline Diagnostics 



2.4.8 Utilities 



2.4.9 Remote 





18 



Xerox Private Data 



2 



DOVE diagnostic elements 



C. Destructive Diagnostic or Utility for the purpose of initial system installation, 
disk drive replacement, or upgrade. 

D. Destructive Diagnostic or Utility for the purpose of troubleshooting or 
peripheral testing. 

2.5.4 Level Four 

Password required 
Availability: 

A. Xerox 

a. NSE/NSC 

b. System Specialist 

c. Manufacturing 

Diagnostic type: 

A. Required diagnostic at Power On 

B. Optional Nondestructive Diagnostic, Online Diagnostic, Offline Diagnostic or 
Utility selectable by all users for extended diagnostics of the system or 
peripheral testing. 

C. Destructive Diagnostic or Utility for the purpose of initial system installation, 
disk drive replacement, or upgrade. 

D. Destructive Diagnostic or Utility for the purpose of troubleshooting or 
peripheral testing. _ 

E. Error Logging 

F. Remote Diagnostics 
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DOVE diagnostics 

by functional subsystem 



This section describes the actual DOVE hardware including special diagnostic hardware 
and the diagnostic tools. It describes the type of diagnostics used to isolate hardware 
failures within each hardware subsystem, and it identifies the FRU list involved. 

3.1 Power supply 

The power supply provides all the DC voltages required by the workstation. The power 
supply is a single FRU. 

The power supply has the following diagnostics hardware: 

• power normal LED 

• test points for each voltage 

The diagnostics used to isolate power supply problems are: 

• Manual Procedures 

The Manual Procedures assist the PSR in isolating AC and DC power problems. 

3.2 Input Output Processor (lOP) 

The Input Output Processor hardware consists of : 

• 80186 processor 

• 16 kbyte EPROM 

• 16 kbyte RAM 

• interrupt controllers 

• timer 

• arbiter 

• host ID PROM 

• system configuration EEPROM 
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DOVE diagnostics by functional subsystem 



The Input Output Processor has the following diagnostics hardware: 

• three general purpose LED status indicators 

• EEPROM (for system configuration and bad memory pages) 

The diagnostics used to isolate hardware errors in the lOP subsystem are: 

• Preboot Diagnostics 

• Boot Diagnostics 

• Offline Diagnostics 

Preboot Diagnostics: 

Preboot Diagnostics are used to verify the following lOP hardware: the 80186 
processor, the 16 kbyte EPROM, the 16 kbyte RAM, the timer, the interrupt 
controllers, the arbiter, the host ID PROM, and the configuration EEPROM. 

The FRU associated with the lOP subsystem Preboot Diagnostics is the lOP PWBA, 
the 6 kbyte EPROM, and the configuration EEPROM. 

Boot Diagnostics: 

Boot Diagnostics are used to verify the following lOP hardware: the interrupt 
controllers, the timer, and the arbiter. 

The FRU list associated with the lOP subsystem Preboot Diagnostics is the lOP 
PWBA. 

Offline Diagnostics: 

The Offline Diagnostics are used to verify the lOP EEPROM. 

The FRU list associated with the lOP subsystem Offline Diagnostics is the lOP PWBA 
and the configuration EEPROM. 

3.3 Mesa processor 

The Mesa processor hardware consists of: 

• control store 

• processor (2901 based for DAYBREAK or S-chip based for DAISY) 

• Mesa processor control logic on the lOP 

The DAYBREAK Mesa processor has the following diagnostics hardware: 

• read control store logic 

• read memory map registers 

• processor reset 

• processor enabled and disabled under program control 
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The DAISY Mesa processor has the following diagnostics hardware: 

• read control store logic 

• read memory map registers 

• S-chip socketed 

• S-chip enabled and disabled under program control 

• history buffer interface 

The diagnostics used to isolate hardware errors in the Mesa processor subsystem are: 

• Boot Diagnostics 

Boot Diagnostics are used to verify the following Mesa processor hardware: control 
store, the processor (2901 for DAYBREAK or S-chip for DAISY), and the Mesa 
processor control logic on the lOP. 

The FRUs associated with the Mesa processor Boot Diagnostics are the lOP PWBA, 
the Mesa processor PWBA, and the backplane. 

3.4 Main memory 

The DAYBREAK main memory hardware consists of : 

• part of the DCM PWBA 

• MEBPWBA 

The DAISY main memory hardware consists of : 

• A-chip for each megabyte of memory 

• first megabyte, part of Mesa processor PWBA 

• main memory will contain from 1/2 megabyte to 4 megabytes 

DAYBREAK diagnostic hardware: 

• force parity 

• memory status register 

DAISY diagnostic hardware: 

• A-chip force parity 

• A-chip read timing control 

• A-chip write timing control 

• A-chip refresh timing control 

• A-chip retains last accessed data 

• A-chip retains last accessed address 

• lOP EEPROM (to maintain bad memory page log) 

Diagnostics used for the main memory: 

• Boot Diagnostics 
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Diagnostics isolation: 

QIC 

Boot Diagnostics will isolate to the memory chip fPiienwFWPipwwiW*, otherwise to 
the board level and to the A-chip. 

The FRUs associated with the main memory Boot Diagnostics for DAYBREAK 
are the DMC PWBA, the MEB PWBA, and memory chips for DAYBREAK. 

The FRUs associated with the main memory Boot Diagnostics for DAISY are the 
Mesa processor PWBA, memory chips, and the A-chip. 



3.5 Rigid disk subsystem 

The rigid disk subsystem hardware consists of: 



• rigid disk DMA controller(on lOP) 

• rigid disk interrupt controller logic (on lOP) 

• rigid disk FIFO (on lOP) 

• rigid disk processor (on lOP) 

• rigid disk cable 

• rigid disk drive 

• drive media 

Diagnostic hardware: 

• diagnostic cylinder 

• special read/write operations for CRC/ECC generator/checker 

• RDC prom lOP-RDC processor communication tests 

Diagnostic hardware tools: 

• external data loopback plug 

The diagnostics used to verify and isolate hardware errors in the rigid disk subsystem are 
(see Table 3.1): 

• Boot Diagnostics 

• Offline Diagnostics 

• Operating System Diagnostics 

• Manual Procedures 



Boot Diagnostics: 

The Boot rigid disk diagnostics are used to verify that portion of the rigid disk 
subsystem which cannot be verified or is difficult to verify using Mesa software. The 
Boot Diagnostics verify rigid disk DMA main memory addressing, rigid disk DMA 
main memory data path, the rigid disk DMA controller, the rigid disk interrupt 
controller logic, and the rigid disk FIFO, 



The Boot Diagnostics use the cursor on the bitmap display in conjunction with Manual 
Procedures to identify the diagnostic tests, data, and the fault codes. 
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The FRUs associated with the rigid disk subsystem Boot Diagnostics are the lOP 
PWBA, the Mesa processor PWBA, and the backplane. 

Offline Diagnostics: 

The Offline Diagnostics for the rigid disk subsystem consist of the Confidence Test, the 
Exerciser, and Surface Verification. 

Confidence Test: 

The Confidence Test does a thorough verification of the rigid disk. It looks for 
hard errors and excessive soft errors. It tests the rigid disk processor, the rigid 
disk cable, the drive and the drive media (user files). 

The Confidence Test is nondestructive. It is run by a customer before placing a 
service call, by the PSR after rigid disk subsystem repair, and any time 
System Verification is run. The Confidence Test uses the bitmap display for 
test description, error data, and FRU data . 

The Confidence Test requires that a physical volume has been created on the 
disk. For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Confidence Test identifies the following FRUs: the TOP PWBA, the rigid 
disk cable, the drive, and the drive media. 

Exerciser: 

The Exerciser exercises the rigid disk hardware thoroughly. It looks for hard 
errors and excessive soft errors. It tests the rigid disk processor, the cable, and 
the drive. 

The Exerciser is a destructive test. It is run by Manufacturing before 
formatting the disk, and by the PSR after replacing a rigid disk drive. The 
Exerciser uses the bitmap display for test description, error data, and FRU 
data. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Exerciser identifies the following FRUs: the lOP PWBA, the cable, and 
the drive. 

Surface Verification: 

Surface Verification verifies the integrity of the media (customer data) on the 
entire disk surface. It looks for hard and soft media errors. 

Surface Verification is a nondestructive test. It is run by the analyst or the 
PSR to check for media problems. It displays all media errors on the bitmap 
display. 
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Surface Verification maintains extended media error data in an error log and 
executed 10 commands a trace table. 

Operating System Diagnostics: 

The Operating System Diagnostics log all encountered rigid disk subsystem errors 
when the Operating System is running. They also analyze and summarize these errors 
on request (see 2.4.6). 

Note: Operating System Diagnostics are not planned for DAYBREAK or DAISY IMO , 
due to resource limits and priorities. 

Manual Procedures: 

Manual Procedures will be used in guiding the PSR in isolating rigid disk cable 
problems (opens, shorts, bad connections). They may also be used to further isolate 
between the drive and the lOP using a pulse probe and a Digital Volt Meter (TBD). 



Table 3.1 Rigid disk subsystem and associated diagnostics 



Rigid Disk 
Hardware 


*Boot 


Offline Diagnostics 


Operating 
System 


Manual 
Procedures 


Confidence 
Test 


Exerciser 


Surface 
•Verification 


DMA 
Controller 


X 


X 


X 




X 




DMA 
Interrupt 


X 


X 


X 




X 




FIFO 


X 


X 


X 




X 




305 
Processor 




X 


X 




X 




305 
Interrupt 




X 


X 




X 




Cable 




X 


X 




X 


X 


Drive 




X 


X 




X 


Xtbd 


Media 




X 




X 


X 





*Uses diagnostic hardware 
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3.6 Ethernet subsystem 

The Ethernet hardware consists of : 



• Ethernet data link controller (on lOP) 

• Ethernet interrupt controller logic (on lOP) 

• Ethernet serial interface (on lOP) 

• transceiver cable 

• transceiver 

• coax cable 



Diagnostic hardware: 

• Ethernet data link controller internal diagnostic turnaround 

• Ethernet data link controller 170 byte status access 

• Ethernet serial interface internal diagnostic turnaround 



Diagnostic hardware tools: 

• built in TDR 

• controller turnaround plug 

• transceiver turnaround plug 

• transceiver 12v LED 



The diagnostics used to verify and isolate hardware errors in the Ethernet subsystem are (see 
Table 3.2): 



• Boot Diagnostics 

• Offline Diagnostics 

• Online Diagnostics 

• Operating System Diagnostics 

• Manual Procedures 



Boot Diagnostics: 

The Boot Diagnostics are used to verify that portion of the Ethernet subsystem which 
cannot be verified or is difficult to verify using Mesa software. The Boot Diagnostics 
verify Ethernet main memory addressing, the Ethernet data link controller diagnostic 
turnaround, and the Ethernet interrupt controller logic. 

The Boot Diagnostics use the cursor on the bitmap display in conjunction with Manual 
Procedures to identify the diagnostic tests and the FRU list. 

The FRUs associated with the Ethernet subsystem Boot Diagnostics are the lOP 
PWBA, the Mesa processor PWBA, and the backplane. 

Offline Diagnostics: 

The Offline Diagnostics for the Ethernet subsystem consist of the Communications 
Test and the Turnaround Tests. 
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Note: The Offline Diagnostics will use the build m TDR for diagnosing net problems, 
and that software is not planned for DAYBREAK or DAISY IMO, due to resource 
limits and priorities. 




Communications Test: 



The Communications Test does a thorough verification of the Ethernet 
subsystem. It looks for hard errors and excessive soft errors. It tests the 
Ethernet data link controller, the Ethernet serial interface diagnostic 
turnaround, the Ethernet serial interface, the transceiver cable, the 
transceiver, and the coax cable. 

The Communications Test is nondestructive. It is run by a customer before 
placing a service call, by the PSR after Ethernet subsystem repair, and any 
time System Verification is run. The Communications Test uses the bitmap 
display for test description, error data, and FRU data . 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Communications Test identifies the following FRUs: the lOP PWBA, the 
transceiver cable, the transceiver, and the coax cable. 

Controller Turnaround Test: 

The Controller Turnaround Test further isolates a problem to the transceiver, 
the transceiver cable, or the lOP. It uses the controller turnaround plug. It 
looks for hard errors and intermittent errors. 

The Controller Turnaround Test is run by the PSR after the Communications 
Test identifies a possible transceiver interface error. The Turnaround Test 
uses the bitmap display for test description, error data, and FRU data. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Turnaround Test identifies the following FRUs: the lOP PWBA, the 
transceiver cable, and the transceiver. 



Transceiver Turnaround Test: 



The Transceiver Turnaround Test further isolates a problem to the transceiver 
or the coax cable. It uses the transceiver turnaround plug. It looks for hard 
errors and intermittent errors. 

The Transceiver Turnaround Test is run by PSR after the Communications 
Test identifies a possible transceiver or Ethernet cable error. The Turnaround 
Test uses the bitmap display for test description, error data, and FRU data. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 
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The Transceiver Turnaround Test identifies the following FRUs: the 
transceiver and the coax cable. 

Online Diagnostics: 

The Online Diagnostics for the Ethernet subsystem consist of the Communications Test. 

Communications Test: 

The Communications Test does a thorough verification of the Ethernet 
subsystem. It looks for hard errors and excessive soft errors. It tests the 
Ethernet data link controller, the Ethernet serial interface diagnostic 
turnaround, the Ethernet serial interface, the transceiver cable, the 
transceiver, and the coax cable. 

The Communications Test is nondestructive. It is run by a customer before 
placing a service call, and by the PSR after Ethernet subsystem repair. The 
Communications Test uses the bitmap display for test description, error data, 
and FRU data . 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Communications Test identifies the following FRUs: the lOP PWBA, the 
transceiver cable, the transceiver, and the coax cable. 

Operating System Diagnostics: 

The Operating System Diagnostics log all encountered Ethernet subsystem errors 
when the Operating System is running. They also analyze and summarize these errors 
on request. 

Note: Operating System Diagnostics are not planned for DAYBREAK or DAISY IMO , 
due to resource limits and priorities. 

Manual Procedures: 

Manual Procedures are used in conjunction with the Turnaround Tests to isolate 
between the lOP PWBA, the transceiver cable, the transceiver, and the coax cable. 
They may also be used in guiding the PSR in isolating transceiver cable problems 
(opens, shorts, bad connections). 
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Table 3.2 Ethernet subsystem and associated diagnostics 



Ethernet 
Hardware 


*Boot 


* Offline Diagnostics 


* Online 
Diagnostics 

ootnniu.ni- 
cations Test 


Operating 
System 


Manual 
Procedures 


*Commum. 
cations Test 


*Turna round 
Test 


Data Link 
Controller 


X 


X 




X 


X 




Ethernet 
Interrupt 


X 


X 




X 


X 




Serial 
Interface 
Controller 




X 


X 


X 


X 




Transceiver 
Cable 




X 


X 


X 


X 


X 


Transceiver 




X 


X 


X 


X 




Coax Cable 




X 




X 







* Uses diagnostic hardware 



3.7 Floppy disk subsystem 

The floppy disk subsystem hardware consists of: 

• DMA controller (on lOP) 

• data separator (on lOP) 

• floppy controller (on lOP) 

• floppy interrupt controller logic (on lOP) 

• drive cable 

• drive 

Diagnostic tool: 

• Diagnostic diskette (This diskette contains a known data pattern on the last cylinder. 
This data pattern is verified before writing on the diskette.) 

The diagnostics used to verify and isolate hardware errors in the floppy disk subsystem 
are (see Table 3.3): 

• Preboot Diagnostics 

• Offline Diagnostics 

• Online Diagnostics 

• Operating System Diagnostics 

• Manual Procedures 
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Preboot Diagnostics: 
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The Preboot Diagnostics include a floppy head-cleaning utility. This utility, resident 
in EPROMs, will allow cleaning the heads without booting software from any boot 
device. This is necessary for instance when the rigid disk is down and diagnostics can't 
be booted from the floppy because the heads need cleaning. 

Offline Diagnostics: 

The Offline Diagnostics for the floppy disk subsystem consist of the Confidence Test 
and the Exerciser. 

Confidence Test: 

The Confidence Test does a thorough verification of the floppy disk. It looks for 
hard errors and excessive soft errors. It tests the DMA controller, the data 
separator, the floppy controller, the floppy interrupt controller logic, the drive 
cable, and the drive. 

The Confidence Test is nondestructive. It is run by a customer before placing a 
service call, by the PSR after rigid disk subsystem repair, and any time 
System Verification is run. The Confidence Test uses the bitmap display for 
test description, error data, and FRU data. 

To be run, the Confidence Test requires a diagnostic floppy diskette. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Confidence Test identifies the following FRUs: the lOP PWBA, the drive 
cable, and the drive. 

The Confidence Test identifies the following CRU; floppy unit. 
Exerciser: 

The Exerciser exercises the floppy disk hardware thoroughly. It looks for hard 
errors and excessive soft errors. It tests the DMA controller, the data 
separator, the floppy controller, the interrupt controller logic, the drive cable, 
and the drive. 

The Exerciser is a destructive test. It is run by Manufacturing and by the PSR 
after replacing an lOP PWBA or a floppy disk drive. The Exerciser uses the 
bitmap display for test description, error data, and FRU data. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The E.xerciser identifies the following FRUs: the lOP PWBA, the drive cable, 
and the drive. 
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Online Diagnostics; 

The Online Diagnostics for the floppy disk subsystem consist of the Confidence Test. 
Confidence Test: 

The Confidence Test does a thorough verification of the floppy disk. It looks for 
hard errors and excessive soft errors. It tests the DMA controller, the data 
separator, the floppy controller, the floppy interrupt controller logic, the drive 
cable, and the drive. 

The Confidence Test is nondestructive. It is run by a customer before placing a 
service call, by the PSR after rigid disk subsystem repair, and any time 
System Verification is run. The Confidence Test uses the bitmap display for 
test description, error data, and FRU data. 

To be run, the Confidence Test requires a diagnostic floppy diskette. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Confidence Test identifies the following FRUs: the lOP PWBA, the drive 
cable, and the drive. 

The Confidence Test identifies the following CRU: floppy unit. 

Operating System Diagnostics: 

The Operating System Diagnostics log all encountered floppy disk subsystem errors 
when the Operating System is running. They also analyze and summarize these errors 
on request . 

Note: Operating System Diagnostics are not planned for DAYBREAK or DAISY IMO , 
due to resource limits and priorities. 

Manual Procedures: 

Manual Procedures will be used in guiding the PSR in isolating floppy disk cable 
problems (opens, shorts, bad connections). They may also be used to further isolate 
between the drive and the lOP using a pulse probe and a DVM (TBD). 
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Table 3.3 Floppy disk subsystem and associated diagnostics 



Floppy Disk 
HardwRrp 


Offline Diagnostics 


Online 
Diagnostics 

Confidence 
Test 


Operating 


Manual 

P vcicpci 1 1 rp 5 


Confidence 
Test 


Exerciser 


DMA 


X 


X 


X 


X 




Data 
Separator 


X 


X 


X 


X 




Floppy 
Controller 


X 


X 


X 


X 




Interrupts 


X 


X 


X 


X 




Drive Cable 


X 


X 


X 


X 


X 


Drive 


X 


X 


X 


X 


Xtbd 



3.8 RS-232-C subsystem 

The RS-232-C hardware consists of : 

• RS-232-C controller (2 channels on lOP) 

• RS-232-C interrupt controller logic (on lOP) 

• RS-232-C cable 

• external device 

Diagnostic tools: 

• RS-232-C turnaround plug 

• DTE port can be looped back to the DCE port with the standard RS-232-C cable 

The diagnostics used to verify and isolate hardware errors in the RS-232-C subsystem are 
(see Table 3.4): 

• Offline Diagnostics 

• Online Diagnostics 

• Operating System Diagnostics 

• Manual Procedures 
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Offline Diagnostics: 

The Offline Diagnostics for the RS-232-C subsystem consist of the Communications 
Test, the Single Channel Turnaround Test and the Dual Channel Turnaround test. 

Communications Test: 

The Communications Test does a thorough verification of the RS-232-C 
subsystem. It looks for hard errors and excessive soft errors. It tests the RS- 
232-C controller, the RS-232-C interrupt controller logic, the RS-232-C cable, 
and parts of the external device. 

The Communications Test is nondestructive. It is run by a customer before 
placing a service call, by the PSR after RS-232-C subsystem repair, and any 
time System Verification is run. The Communications Test uses the bitmap 
display for test description, error data, and FRU data . 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Communications Test identifies the following FRUs: the lOP PWBA, the 
RS-232-C cable, and the external device. Note: If a character printer is 
connected to one of the channels, see the Character Printer Diagnostic 
description. 

Single Channel Turnaround Test: - - 

The Single Channel Turnaround Test further isolates a problem to the lOP 
PWBA, the cable, or the external device. It uses the RS-232-C turnaround 
plug. It looks for hard and intermittent errors. 

The Single Channel Turnaround Test is run by the PSR after the 
Communications Test identifies an RS-232-C interface problem. The Single 
Channel Turnaround Test uses the the bitmap display for test description, 
error data and FRU data. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Single Channel Turnaround Test identifies the following FRUs: the lOP 
PWBA, the RS-232-C cable, and the external device. 

Dual Channel Turnaround Test: 

The Dual Channel Turnaround Test further isolates a problem to the lOP 
PWBA, the cable, or the external device. It uses the RS-232-C cable for 
turnaround. It looks for hard and intermittent errors. 

The Dual Channel Turnaround Test is run by the PSR after the 
Communications Test identifies an RS-232-C problem. The Dual Channel 
Turnaround Test uses the the bitmap display for test description, error data 
and FRU data. 
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For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Dual Channel Turnaround Test identifies the following FRUs: the lOP 
PWBA, the RS-232-C cable, and the external device. 

Note: The Dual Channel Turnaround Test is not planned for DAYBREAK or 
DAISY IMO, due to resource limits and priorities. 

Online Diagnostics: 

The Online Diagnostics for the RS-232-C subsystem consist of the Communications Test. 
Communications Test: 

The Communications Test does a thorough verification of the RS-232-C 
subsystem. It looks for hard errors and excessive soft errors. It tests the RS- 
232-C controller, the RS-232-C interrupt controller logic, the RS-232-C cable, 
and parts of the external device. 

The Communications Test is nondestructive. It is run by a customer before 
placing a service call, and by the PSR after RS-232-C subsystem repair. The 
Communications Test uses the bitmap display for test description, error data, 
and FRU data . 

For extended error data, errors are- kept in an error log and executed 
commands are kept in a trace table. 

The Communications Test identifies the following FRUs: the lOP PWBA, the 
RS-232-C cable, and the external device. 

Operating System Diagnostics: 

The Operating System Diagnostics log all encountered RS-232-C subsystem errors 
when the Operating System is running. They also analyze and summarize these errors 
on request. 

Note: Operating System Diagnostics are not planned for DAYBREAK or DAISY IMO , 
due to resource limits and priorities. 

Manual Procedures: 

Manual Procedures will be used in guiding the PSR in isolating RS-232-C cable 
problems (opens, shorts, bad connections). 
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Table 3.4 RS-232-C subsystem and associated diagnostics 



RS-232-C 
Hardware 


* Offline Diagnostics 


wniine 
Diagnostics 

Communi- 
cations Test 


operating 
System 


Manual 
Procedures 


Communi- 
cations Test 


*Turnaround 

Test 


RS-232-C 
Controller 


X 


X 


X 


X 




Interrupts 


X 


X 


X 


X 




RS-232-C 
Cable 


X 


X 


X 


X 


X 


External 
Device 


X 


X 


X 


X 





*Uses diagnostic hardware 



3.9 Keyboard/mouse/speaker subsystem 

The keyboard/mouse/speaker subsystem hardware consists of : 

• keyboard UART (on lOP) 

• keyboard interrupt controller logic (on lOP) 

• keyboard 

• keyboard cable 

• mouse 

• speaker logic (on lOP) 

• speaker 

Diagnostic hardware: 

• keyboard UART internal loopback 

• keyboard transmits mouse coordinates every half second 

The diagnostics used to verify and isolate hardware errors in the keyboard/mouse/speaker 
subsystem are (see Table 3.5): 

• Preboot Diagnostics 

• Offline Diagnostics 

• Online Diagnostics 

• Manual Procedures 

Preboot Diagnostics: 

The Preboot Diagnostics are used to verify the keyboard UART, the keyboard 
interrupt controller logic, keyboard/mouse coordinates transmission, the speaker 
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logic, and the speaker. The keyboard UART verification uses the keyboard UART 
turnaround logic. 

The Preboot Diagnostics use the cursor on the bitmap display in conjunction with 
Manual Procedures to identify the diagnostic tests and the FRU list. 

The FRUs associated with the keyboard/mouse/speaker subsystem Preboot 
Diagnostics are|the lOP PWBA, the keyboard, the keyboard cable, the mouse, and the 
speaker. 

The CRUs associated with the keyboard/mouse/speaker subsystem Preboot 
Diagnostics are the keyboard, the keyboard cable, the mouse, and the display (for 
speaker). 

Offline and Online Diagnostics: 

The Offline and Online Diagnostics for the keyboard/mouse/speaker subsystem consist 
of the Keyboard/Mouse/Speaker Test. 

Keyboard/Mouse/Speaker Test: 

The Keyboard/Mouse/Speaker Test does a thorough verification of the 
keyboard/ mouse/speaker subsystem. All errors are detected by the user. It 
displays the key depressions on the keyboard, the mouse X and Y coordinate 
motion, and speaker tone including frequency. 

This test is nondestructive. It is run by a customer before placing a service call, 
by the PSR after keyboard/mouse/speaker subsystem repair, and any time 
System Verification is run. The Keyboard/Mouse/Speaker Test depends on 
Manual Procedures for FRU data . 

The FRUs associated with the keyboard/mouse/speaker subsystem are the lOP 
PWBA, the keyboard, the keyboard cable, the mouse, and the speaker. 

The CRUs associated with the keyboard/mouse/speaker subsystem are the 
keyboard, the keyboard cable, the mouse, and the display (for speaker). 
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Table 3.5 Keyboard/mouse/speaker subsystems and associated diagnostics 



Keyboard/ 
Mouse/ 

h-/ d *». w i. 

Hardware 


*Preboot 


v/iiiiiit; 
Diagnostics 

Keyboard/ 
Mouse/ 
Speaker Test 


\_/iiiirie 
Diagnostics 

Keyboard/ 
Mouse/ 
Speaker Test 


Manual 

X X v/v«w\Xvix 


Keyboard 
UART 


X 


X 


X 




Keyboard 
Interrupt 


X 


X 


X 




Keyboard 




X 


X 


X 


Mouse 




X 


X 


X 


Speaker 
Logic 




X 


X 




Speaker 




X 


X 


X 



*Uses diagnostic hardware 



3.10 Display subsystem 

The DAYBREAK display subsystem hardware consists of : 

• DCM PWBA 

• display 

The DAISY display subsystem hardware consists of: 

• display controller (on Mesa processor PWBA) 

• display 

DAYBREAK diagnostic hardware : 

• write and read display controller horizontal and vertical event control store 

• read data-chip status register 
- • read cursor status register 

• read display memory interface chip status register 

• read 4 bits of video data 

DAISY diagnostic hardware : 

• read cursor registers 



18 



Xerox Private Data 



DOVE Program Diagnostic Strategy - Version 5.0 



3 



The diagnostics used to verify and isolate hardware errors in the display subsystem are 
(see Table 3.6): 

• Offline Diagnostics 

• Online Diagnostics 

• Manual Procedures 

Offline and Online Diagnostics: 

The Offline and Online Diagnostics for the display subsystem consist of the Display 
Test. 

Display Test: 

The Display Test shows display alignment patterns. These patterns can be 
used to visually detect display malfunctions and/or to align the display. 

This test is nondestructive. It is run by a customer before placing a service call, 
by the PSR after displaying subsystem repair, and any time System 
Verification is run. The Display Test depends on Manual Procedures for FRU 
data . 

The identified FRUs for DAYBREAK are: the DCM PWBA and the display. 

The identified FRUs for DAISY are: the lOP PWBA, the Mesa processor 
PWBA, and the display. - - 

The identified CRUs both for DAYBREAK and DAISY are: the display. 



Table 3.6 Display subsystems and associated diagnostics 



Display 
Hardware 


♦Offline 
Diagnostics 

Display Test 


♦Online 
Diagnostics 

Display Test 


Manual 
Procedures 


A-chip 


X 


X 




Display 


X 


X 


X 



♦Uses diagnostic hardware 
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3.11 Character printer subsystem 

The character printer subsystem hardware consists of : 

• RS-232-C controller (on lOP) 

• RS-232-C interrupt controller logic (on lOP) 

• character printer 

• diagnostic tools: 

RS-232-C turnaround plug 

The diagnostics used to verify and isolate hardware errors in the character printer 
subsystem are (see Table 3.7): 

• Offline Diagnostics 

• Online Diagnostics 

• Operating System Diagnostics 

• Manual Procedures 

Offline Diagnostics: 

The Offline Diagnostics for the character printer subsystem consist of the Confidence 
Test, the Single Channel turnaround test, and the alignment tests. 

Confidence Test: 

The Confidence Test tests all the options of the character printer. It looks for 
hard errors and intermittent errors. It tests the RS-232-C controller, the RS- 
232-C interrupt controller logic, the character printer cable, and the character 
printer. The majority of the hardware errors must be identified visually with 
the assistance of manual procedures. 

The Confidence Test is run by a customer before placing a service call, by the 
PSR after character printer subsystem repair, and any time system 
verification is run. It uses the bitmap display for test description, error data, 
and FRU data. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Confidence Test identifies the following FRUs: the lOP PWBA, the 
character printer cable, and the character printer. 

The Confidence Test identifies the following CRUs: the character printer 
cable, and the character printer. 

Single Channel Turnaround Test: 

The Single Channel Turnaround Test further isolates a problem to the lOP 
PWBA, the cable, or the character printer. It uses the RS-232-C turnaround 
plug. It looks for hard and intermittent errors. 
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The Single Channel Turnaround Test is run by the PSR after the Confidence 
Test identifies a RS'232-C interface problem. The Single Channel Turnaround 
Test uses the the bitmap display for test description, error data and FRU data. 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Single Channel Turnaround Test identifies the following FRUs: the lOP 
PWBA, the RS-232-C cable, and the character printer. 

Alignment Tests: 

The Alignment Test displays alignment patterns. These patterns can be used 
to visually detect mechanical alignment problems. These tests are run by the 
PSR when the Confidence Test identifies an alignment problem. 

Online Diagnostics: 

The Online Diagnostics for the character printer subsystem consist of the Confidence 
Test. 

Confidence Test: 

The Confidence Test tests all the options of the character printer. It looks for 
hard errors and intermittent errors. It tests the RS-232-C controller, the RS- 
232-C interrupt controller logic, the character printer cable, and the character 
printer. The majority of the hardware errors must be identified visually with 
the assistance of Manual Procedures. 

The Confidence Test is run by a customer before placing a service call, by the 
PSR after character printer subsystem repair, and any time System 
Verification is run. It uses the bitmap display for test description, error data, 
and FRU data . 

For extended error data, errors are kept in an error log and executed 
commands are kept in a trace table. 

The Confidence Test identifies the following FRUs: the lOP PWBA, the 
character printer cable, and the character printer. 

It identifies the following CRUs: the character printer cable, and the character 
printer. 

Operating System Diagnostics: 

The Operating System Diagnostics log all encountered character printer subsystem 
errors when the Operating System is running. They also analyze and summarize these 
errors on request. 

Note: Operating System Diagnostics are not planned for DAYBREAK or DAISY IMO , 
due to resource limits and priorities. 
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Table 3.7 Character printer subsystem and associated diagnostics 



Character 
Printer 


Offline 
Diagnostics 

Confidence Test 


Online 
Diagnostics 

Confidence Test 


Operating 

System 
Diagnostics 


Manual 
Procedures 




X 


X 


X 




RS-232-C 
Interrupt 


Y 
A 


Y 
A 


Y 
A 




Cable 


X 


X 




X 


Character 
Printer 


X 


X 


X 





3.12 PC emulation option 

The PC emulation option PWBA consists of : 

• Intel 80186 processor ~" * 

• 10 trapper hardware 

• display trapper hardware 

The diagnostics used to verify and isolate hardware^errors in the PC emulation option are: 

• Boot Diagnostics 

• Online Diagnostics 

Boot Diagnostics: 

Boot Diagnostics are used to verify the 80186 processor, the 10 trapper hardware, and 
the display trapper hardware. Note: There is no special 80186 instruction test, instead 
the assumption is that the 80186 processor is functional after being used to verify the 
10 trapper hardware and the display trapper hardware. 

Boot Diagnostics are run by the PSR after PC emulation subsystem repair. They use 
the cursor for test description, error data, and FRU data. 

Boot Diagnostics identify the following FRUs: the lOP PWBA, the PCE option PWBA, 
and the memory processor PWBA for DAISY, or DCM PWBA for DAYBREAK. 

Online Diagnostics: 

The Online Diagnostics for the PC emulation option consist of the Confidence Test. 
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Confidence Test: 

The Confidence Test tests all the options of the PC emulation option. It looks 
for hard errors and intermittent errors. 

It is run by a customer before placing a service call, and by the PSR after PC 
emulation subsystem repair. The Confidence Test uses the bitmap display for 
test description, error data, and FRU data. 

The Confidence Test identifies the following FRUs: the lOP PWBA, the PCE 
option PWBA, and the memory processor PWBA for DAISY, or DCM PWBA 
for DAYBREAK. 
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4.1 Manufacturing QA Acceptance (extended) 

The purpose of the Manufacturing Quality Assurance Acceptance (extended) is to verify 
that the system has been assembled properly and is ready to ship. The Acceptance Test 
determines the reliability of the system, based upon pre-defined criteria, to quantify 
whether the system passes or fails. Passing this test indicates that the system is reliable 
for customer usage. The test monitors the health (reliability) of the electronics, notifies an 
operator of conditions requiring attention, and recommends maintenance action. It 
determines the reliability of the electronics by observing its previous error trends and 
then, by extrapolation, predicts future error trends. 

The personnel expected to operate the Acceptance Test in manufacturing is a skilled 
technician. 

4.2 Installation verilHication 

The purpose of an installation verification diagnostic is to insure that all components of a 
system that have been installed are operating properly. The installer will run Preboot and 
Boot to check out the base unit followed by Offline Diagnostics set to run automatically 
until completion. The diagnostic should exercise the base unit and every peripheral 
attached to the base system that is set up in the configuration EEPROM. All subsystems 
that don't respond, indicate not ready, or have a fault, will be indicated on the display at 
completion of testing. Subsystems that indicate not ready or don't respond, can be selected 
to run by the installer. All fault indications are to be repaired using fault isolation 
procedures described below. 

The users of installation diagnostics are all the users described in Section 2.1 of this 
document. 

4.3 Fault isolation 

The purpose of the fault isolation diagnostic is to find a fault in the system that has caused 
the operator to request service. The diagnostic packages that are used for fault isolation 
are Preboot, Booy Offline, Online, Operating System Diagnostics, Acceptance Test 
Procedures, Utilities, and Remote. These procedures are described in Section 2.4 of this 
document. Fault isolation diagnostics should be able to pinpoint the fault to a single FRU 
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eighty percent of the time, two FRUs fifteen percent of the time, three or more FRUs 4.9 
percent of the time, and the system is not diagnosable 0.1 percent of the time. Fault 
isolation diagnostics should run for the shortest time possible so the PSR goal for MTTR is 
met. The MTTR goal for a PSR is for the average repair to take less than fifteen minutes 
for a single system failure, and in 99.8 per cent of the cases the MTTR shall not exceed 45 
minutes. The PSR is expected to be able to complete ninety five percent of Dove service 
calls without assistance. 

The users of fault isolation diagnostics are the customer user, customer user support 
person. Product Support Representative, Customer Support Representative, Region 
Engineering Specialist, Network System Consultant, Network System Engineer, 
Network Support Center, Manufacturing Technician, System Administrator, and System 
Analyst. These users are described in Section 2.1 of this document. Some of the users 
described above will only be able to run a subset of the fault isolation diagnostics because 
of the limited training ^^mMMUkmm . _^^^„mm^ 



The purpose of the extended fault isolation diagnostic is to find a fault in the system that 
has caused numerous service calls and has not been detected by the normal fault isolation 
diagnostic. Many of these faults are intermittents and the only method of finding them is 
to run a diagnostic that will execute for several hours while logging the errors 
encountered. The extended fault isolation diagnostics are Boot and Offline Diagnostics 
that are used in a looping or automatic mode to do in-depth testing and logging of errors 
that occur during the testing. _ 

The users of extended fault isolation diagnostics are the customer user support person, 
Product Support Representative, Customer Support Representative, Region Engineering 
Specialist, Network System Consultant, Network System Engineer, Network Support 
Center, Manufacturing Technician, System Administrator, and System Analyst. 



The purpose of the repair verification diagnostics is to insure that any fault which has 
required service has been fixed and that in repairing the fault, no other faults have been 
created. An example of this would be if an lOP PWBA had been replaced because of a rigid 
disk controller failure, then the controllers for the display, keyboard, floppy disk, RS-232, 
and Ethernet must be verified. These diagnostics are the same as fault isolation 
diagnostics, but for verification the short version would be used in testing the subsystems 
that hadn't failed on the replaced FRU. Service procedures will instruct the technician 
which tests to run following a repair. 

The users of repair verification diagnostics are the customer user support person, Product 
Support Representative, Customer Support Representative, Region Engineering 
Specialist, Network System Consultant, Network System Engineer, Network Support 
Center, and Manufacturing Technician. 



4.4 Extended fault isolation 




4.5 Repair verification 
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4.6 Peripheral isolation 

The purpose of the peripheral isolation diagnostic is to determine whether the subsystem 
fault that was detected is in the peripheral or in the peripheral controller. This is 
sometimes done with internal loopback and sometimes by external loopback tools or 
cables in conjunction with Boot and Offline Diagnostics. When neither the internal nor 
external loopbacks are practical the peripheral isolation is done by manual procedures 
and check charts. 



The users of Pheripheral Diagnostics are the customer user support person, Product 
Support Representative, Customer Support Representative, Region Engineering 
Specialist, Network System Consultant, Network System Engineer, Network Support 
Center, and Manufacturing Technician. 

4.7 Communications isolation and verification 

The purpose of the communications isolation and verification diagnostic is to determine 
directly or remotely if the system and the network to which it is attached are functioning 
properly. This is done with Online Diagnostics that perform echo and/or direct 
communication with or through repeaters, communication services, file services, dial up 
services, workstations, print services, and gateways. 

Communications isolation and verification diagnostics are a subset of Online diagnostics 
and are used by the Customer User Support Person, Product Support Representative, 
Customer Support Representative, Region Engineering Specialist, Network System 
Consultant, Network System Engineer, Network Support Center, Manufacturing 
Technician, System Administrator, and System Analyst. 



4.8 Utilities 



Utilities are a a collection of softwEllce packages that are used in conjunction with 
diagnostics and other system softwarer^^ome examples of Utilities are rigid and floppy 
disk scavenging, rigid and floppy disk formatting, floppy disk head cleaning, floppy disk 
copying, EEPROM configuration bit setting, and option slot diagnostic and printer 
diagnostics. Utilities are written in Mesa, use the display for the user interface, and 
operate in the interactive mode. 

The users of Utilities are the Customer User Support Person, Product Support 
Representative, Customer Support Representative, Region Engineering Specialist, 
Network System Consultant, Network System Engineer, Network Support Center, 
Manufacturing Technician, System Administrator, and System Analyst. 
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5.1 Diagnostic validation 



To insure the diagnostic effectiveness of repairing the DOVE machine when a single 
failure occurs in the system, DOVE designers shall initiate a plan to do fault insertion 
testing of the system. The fault insertion testing plan should be thorough^ftSJUSSbtd! 



demonstrate diagnostic's ability to meet its plan of repairing with a single FRU eighty 
percent of the time, two FRUs fifteen percent of the time, and three or more FRUs 4.9 
percent of the time. It is estimated that the system will be non-^^lwtt»Je To percent of 
the time. The test result must also demonstrate the ability of the system to meet the Mean 
Time To Repair for a PSR service call. The Mean Time To Repair goal for a PSR is for the 
average service call to be less than fifteen minufes for a single system failure in 99.8 
percent of the cases, and shall not exceed 45 minutes. The PSR is expected to repair 
ninety-five percent of all service calls. 

There shall be provisions in the testing plan which include preliminary fault insertion 
testing on the prototype hardware and early software, on the preproduction hardware, and 
on the final production hardware before IMO. The results of the testing will be used to 
improve the hardware and software where the diagnostic effectiveness has not met the 
diagnostic plan. The result will also be used by Service to project service cost impact where 
the diagnostic plan will never be met because of the impact to UMC. 

An example of a test plan can be found in Appendix i£. A minimum number of 300 faults 
must be inserted. The number of faults inserted in each subsystem is proportional to the 
probability of a fault occurring in that subsystem. Below is a list of the subsystems and the 
minimum number of faults to be inserted in each subsystem. 




Subsystem 



Minimum number of faults inserted 



186 bus 

MPB-DCM bus 
lOP-S-chip bus 
lOP-PCE bus 
Expansion address bus 
Expansion data bus 
Memory system 
Rigid disk 



TED 
TBD 
TBD 
TBD 
TBD 
TBD 
TBD 
TBD 
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Subsystem 

Ethernet 
PCE 

Power system 
Floppy disk 
Keyboard 
Display 
RS-232-C DCE 
RS-232-C DTE 



Minimum number of faults inserted 

TBD 
TBD 
TBD 
TBD 
TBD 
TBD 
TBD 
TBD 
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6.1 Diagnostic sources 

6.1.1 Sources of diagnostic hardware 

• Some diagnostics hardware has been included in the DOVE system design. This 
includes internal turnaround capabilities and provisions for support of external 
diagnostic tools. 

• Turnaround plugs or special cables can be ordered through Distribution. 

• The optional maintenance panel can be ordered through TBD. 



6.1.2 Sources of diagnostic software 

• Manual Procedures iwi^described in the Field Service documentation. 

• Preboot Diagnostics are located in the lOP EPROMs. 

• Boot Diagnostics are available from several sources: floppy disk, Ethernet, and rigid 
disk. ^ ft 

• Offline Diagnostics reside or^Ethernet boot servers or floppy disks. 

• Online Diagnostics reside on the local rigid disk. 




6.2 DisT 




tic testing and verification 

as the needs dictate. Therefore^ 



DiagnosticsVi-U^ up 
will be on-going. 



However, in each phase of the desi^^^^f^lioation and qualification tests [A, B, and C] the 
diagnostics will be tested^J,|i?^KeX-Qualificauc^ faults will be induced to test and 
validate the proc^uf^fmsure faults are correctly ide?tti^^, and the process completed 
withint]3^B'*9!lTocated time. Qualification testing applies omy**t^^the initial release of 
ktgfiostics. 



sting and verification 
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mg build oi the machines over a period of 
startup of over six months. 




Diagnostic§*'w4iLlie tested durin 
^T"T mnnfhi i iml i li ii iiii' iFn iiiil i il ma 



6.3 Diagnostic distribution and updates 

The various types of diagnostics will be distributed differently. 

Except for the maintenance panel and the turnaround cables, the diagnostic hardware 
will be contained in the system. Updates may occur and will be released as change notices 
with the part number of the hardware updated to reflect this change. The maintenance 
panel and turnaround cables must be ordered separately. 

The diagnostic software will be upgraded and released periodically. Diagnostics updates 
' will be distributed on floppy disks or over the Ethernet, with the exception of Preboot 
updates. Preboot changes require a hardware change, that is, replacing the EPROMs. 



6.4 Diagnostic documentation 



Each level of diagnostic software will be documented, including a discussion of the 
hardware tested, the options available to users of the diagnostics, the meaning of all error 
messages and codes, and suggested recovery actions. Preboot Diagnostics will be described 
in both customer and field service documentation. Engineering will provide 
manufacturing with appropriate documentation defining the contents of each version of 
the EPROMs. Boot, Offline, and Online Diagnostics will be documented by Engineering as 
a part of each Office Systems release. In additions, Jthere will be customer and field service 
documentation for Boot, Offline, and Online Diagnostics. The Acceptance Tests Package 
will be described by Engineering in a document for use by manufacturing. 

Whenever changes are made to any diagnostics, the systems documentation indentured 
list will reflect the proper diagnostic number. 



6.5 Diagnostic documentation release control 

After the initial release, all subsequent releases will be controlled either by the hardware 
or the software release control mechanism. In either case, there will be some form of 
review board committee to understand the impact of the benefits versus the cost of the 
pending release. 

6.6 Diagnostic availability and implementation priorities 

This document outlines all the diagnostics which are currently envisioned for DOVE. Not 
all of them will be available for the DAYBREAK launch, due largely to software 
development priorities and resource constraints. Assuming no redirection from OSD Core 
Systems, all the diagnostic software described in this document will be implemented for 
DOVE, but will be released at different times. The current implementation priorities and 
schedules for diagnostic software are, in descending order of priority: 
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Planned for DAYBREAK launch: 

1. Preboot, Boot, Offline (rigid disk), 

Online (floppy disk, RS-232-C port, Ethernet, keyboard and mouse, display, 
optional local printer, PC emulation option card) 

2. Acceptance tests 

3. Offline (Ethernet) 

4. Offline (keyboard and mouse, display) 

5. Memory error management (mapping out bad pages; requires hooks in the 
debugger substitute, the initial lOP code, and the boot diagnostics; see 
Appendij^) 

e 

Planned for DAISY launch: 

6. Offline (floppy disk) 

7. Offline (RS-232-C port, TTY port) 

8. Remote interface to offline diagnostic 

9. Offline (optional local printer) 
Post DAISY launch: 

10. Operating system diagnostics (automatic soft error logging, perhaps by a 
network diagnostic monitoring service) 
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DOVE machine configuration 
management 



This section describes how the various DOVE configurations are detected and'managed by 
the system software that runs on the machine. There are two elements to be considered 
with regard to configuration management. The first is the medium that is used to store the 
information. This information must obviously be machine readable, and of a semi- 
permanent nature. That is, it should remain in the system when the power is turned off, 
and it must be able to be readily changed, although on an infrequent basis. The second 
element is the actual information that is to be stored in the medium and how it is to be 
managed. Section A.l will consider the configuration storage medium requirements, 
Section A. 2 some implementations, and Section A. 3 will discuss the information contained 
therein and how it is managed. 

A.l Configuration storage medium 

Since there are a variety of peripherals, I/O devices, and memory sizes that can be 
connected to a DOVE machine, there needs to be some method for the system software and 
diagnostics to dynamically determine what the current configuration is. In addition, due 
to some differences between software that runs on a DAISY machine as opposed to a 
DAYBREAK machine, it also needs to be determined on which of the two DOVE machines 
the software is running. 

Thus, there are to be some number of bits available to the lOP indicating the nature of the 
peripherals, as well as a special bit denoting either the DAISY or DAYBREAK machine. 
These bits will be infrequently read by the software, and will be changed by a human each 
time the configuration or implementation of the machine is physically changed. This 
information needs to be retained after the machine is powered down. The implementation 
should provide a convenient, error-free method of setting the bits, and be realized with as 
little UMC and board area as possible. 

At present, there is a need for about 30 configuration bits identified. These include the 
DAISY/DAYBREAK bit, and bits for memory size, rigid disk type, floppy disk presence 
and type, display type, Ethernet presence, keyboard type, and other optional devices 
present. Since the DAISY/DAYBREAK bit is a special type, it is implemented by the 
particular Mesa processor which is plugged into the card-cage. The lOP will read the bit 
from the backplane. 
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There are several possibilities for implementing the storage of configuration information, 
including the rigid disk, the floppy disk, using unique cables, DIP switches, and EEProms. 
For various reasons, it has been decided that EEProms will be used for the configuration 
information medium [reference: DOVE Machine Configuration, DOVE Diagnostic Team 
design note, May 14, 19841. 

An BEProm is an EProm that can be electrically erased and written. Like an EProm, it 
retains its contents aifter the power has been turned off. (A similar device is called a non- 
volatile RAM, or NOVRAM. This device essentially is a RAM with a shadow EEProm. 
Before the power is turned off, the RAM information has to be transferred to the EEProm, 
and re-read after power is turned on again. Extra external circuitry is needed to control 
these transfers, and they are usually of higher cost. Thus, this form of memory is not 
considered further.) 

An EEProm is included as an lOP I/O device and can be read when needed. The EEProm 
can be written under control of lOP software. A special software tool will be needed to 
insert or change the configuration information. This method provides flexibility by 
providing a substantial amount of information at a relatively low cost. 

Two possible EEProm implementations have been considered. A final decision has not yet 
been made of which implementation to use. The first etch of the lOP will support both 
cases. The next section discusses two possible EEProm implementations and makes a 
recommendation for a preferred scheme. 

A.2 EEProm implementation alternatives 

An EEProm is a cost-effective way to store a significant amount of readable and writeable 
non- volatile information. All the EEProms described below are + 5V only, and thus do not 
require any special power supply voltages. They are relatively easy to read and write. The 
types considered below are either parallel in/out, or serial in/out. The serial EEProms are 
more complicated to access from a software point of view, but have low cost and small 
board area. EEProms still tend to be single-sourced devices and not compatible from 
manufacturer to manufacturer. 

Case 1: 64 x 16 Serial EEProm 

In this implementation, the National NMC 9346 serial EEProm is used. The EEProm is 
organized as a 64 x 16 memory, which is serially accessed. This provides IK bits of storage. 
The part is packaged in S-pin DIPs and requires a small amount of board space. This part 
is a larger version of the NMC 9306 which is organized as 16 x 16. (The latter EEProm is 
not usable due to a frequency limitation of the part.) The advantages of this scheme are its 
low cost (approximately $3.50) and small board area (about 1 sq. in.). The disadvantage is 
that the part is not yet in production. Full production is planned for October-November 
1984. (The NMC 9306 is already in full production, so it is not anticipated that there will 
be production problems with the larger part.) An additional disadvantage is that the 
software overhead to access the part is higher than the parallel devices. This access is, 
however, infrequently made. 

Case 2: 2K x 8 Parallel EEProm 

In this implementation, the Intel 9817A is used. The EEProm is organized as a 2K x 8 
memory and is read and written in parallel. The main advantage is that the software 
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access is simple, and that there is a large amount of memory storage available. The main 
disadvantages are the cost of the scheme (about $16.00) and the board area required 
(about 3 sq. in). Extra address decoding circuitry is needed, and the part is a 28-pin device. 

Table A.l compares the two scheme designs using the various parameters mentioned 
above. 



Table A.l EEProm implementation comparison 



Parameter 


Case 1 


Case 2 


Access method 


Serial 


Parallel 


Organization 


64x16 


2Kx8 


UMC 


$3.50 


$16 


Board area (sq. in.) 


1 


3 



Discussion 

From the above table it can be seen that the serial implementation clearly has an 
advantage over the other schemes in terms of UMC and board area. The extra software 
overhead to access the information is not thought to be a problem, since it is infrequently 
done and is part of a special tool. It is felt that IK worth of bits is more than adequate for 
storing configuration information. (It might notjbe^dequate for storing memory and disk 
bad pages, however.) The only significant risk is that the part is not yet in production. 

Recommendation: It is recommended that the serial implementation (Case 1) be 
incorporated into the second etch. This is due to cost and area advantages. (Note that 
every extra $1 UMC translates into about $80,000 extra program UMC over the life of the 
DOVE program.) At the time of second etch, we will know if there is still any risk due to 
the production status of the National part. If there still is, the backup implementation can 
be the other case. Meanwhile, as mentioned above, the first etch will implement both 
alternatives. This recommendation will be implemented unless there is redirection 
resulting from a DOVE Diagnostic Team consensus, or from the Program. 

A.3 Connguration information description and management 
The configuration utility 

There will be a floppy- or Ethernet-bootable configuration utility that will allow 
initializing and modifying the configuration EEPROM. Setting the EEPROM is a manual, 
menu-driven process. The configuration utility will not be able to do it automatically, 
because the hardware is not completely self-identifying. This utility will be based on 
UtilityPilot and written in Mesa. It will be similar to the disk initialization utility, and 
could possibly be incorporated into that utility. 

A safe default configuration 

The management of the configuration EEPROM must be carefully thought out to avoid 
any circular dependencies. One such circular dependency could occur if the EEPROM were 
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required to be initialized before the configuration utility program could be booted to 
initialize it. The strategy to avoid this predicament is to substitute a safe default 
configuration whenever the EEPROM is found to be invalid or uninitialized. The default 
configuration, must allow the configuration utility to be booted and run. 

The important parameters of the safe default configuration are memory size, display, 
floppy disk, and Ethernet. It should be safe to set the memory to the smallest allowable 
size, the display to "experiment," the floppy disk to "both types present," and the Ethernet 
to present. Note that two backplane signals will identify the processor type (currently 
either DAYBREAK or DAISY). 

For the display, "experiment" instructs the lOP boot code to experiment with the display 
controller to determine which crystal oscillator is installed and thus which type of display 
is expected. This involves timing the interval between vertical retrace interrupts. For 
each supported display, this interval will be different. Once the display type has been 
identified, the display controller can be correctly initialized to allow use of the display by 
the configuration utility. 

For the floppy disk, "both types present" means that both types of floppy disks should be 
assumed to be present. This would allow the user to boot from whichever type of floppy is 
present, if there is one. 

An alternate strategy for the floppy would be to reserve a fixed location in a sector on 
cylinder 0, head 0, of every floppy diskette for floppy drive type information. This would 
require that all DOVE floppies be formatted identically on the track on cylinder 0 under 
head 0, so that no knowledge of the floppy drive type would be required to read that track. 

The safe default configuration should allow a configuration utility program to be booted 
from either type of floppy or Ethernet and use the display, regardless of type. This strategy 
requires the ability to distinguish invalid and uninitialized EEPROMs from valid 
EEPROMs. By including a word of checksum followed by its complement in the EEPROM, 
it should be virtually impossible for an uninitialized or otherwise invalid EEPROM to 
appear valid. 

Managing the EEPROM contents 

Managing the contents of the configuration EEPROM can be divided into three phases: 

1. setting it initially when the machine is configured prior to shipping. 

2. reading it during system initialization while booting. 

3. changing it whenever the hardware configuration (or other EEPROM 
information) is changed. 

Setting it before shipping 

When a DOVE workstation is configured prior to shipping, the configuration utility 
should be run to set the EEPROM correctly. This is when the safe default configuration 
will be used most. 

Reading it during booting 

The lOP booting code in EPROM will read the configuration EEPROM early in booting in 
order to present the user with the correct set of boot device choices, among other things. It 
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will verify the checksum and its complement in the EEPROM before trusting it. If the 
checksum or complement is incorrect, the booting code will post an error indication in the 
LED status indicators. A keystroke from the user is required to continue after an 
EEPROM error is indicated. This will cause the booting code to try to complete the booting 
process using the safe default configuration. The user should try to boot the configuration 
utility and attempt to reset the configuration EEPROM, assuming the checksum problem 
is only transitory. If the problem is persistent, then the lOP (the FRU containing the 
EEPROM) will have to be replaced, and the new EEPROM reset. 

There should be a way to force the booting code to use the safe default configuration. This 
would be necessary, for instance, if the EEPROM checksum and complement are valid but 
the indicated configuration is set incorrectly. It should be possible to circumvent the 
EEPROM manually by holding down a special key during booting. 

Changing it when the hardware is changed 

When the hardware configuration is changed, the configuration utility should be run to 
change the EEPROM appropriately. It should be possible to change the EEPROM before 
changing the hardware, if that is ever required, since the EEPROM will probably be read 
during initialization only. 

Rigid disk backup 

If possible, the EEPROM configuration information should be backed up on the rigid disk. 
This facilitates restoring the configuration information to the EEPROM after replacing 
the lOP/RDC board, which contains the EEPROM. - 

It should be possible to reserve a sector on the rigid disk for backing up the EEPROM 
contents. A good candidate is the sector where we currently put the first page of the initial 
microcode. The initial microcode could start on the following page on DOVE machines, 
since this location is allowed to be processor-dependent. It should be possible to read this 
page without knowing the type of disk. If not, a less attractive alternative would be to 
require the user to manually specify the type of the disk to the configuration utility. 

Note that it would probably be unwise to store the configuration information only on the 
disk, and not include an EEPROM on DOVE. One reason is the significantly lower 
reliability of disk memory compared to EEPROM memory. Couple that with the fact that 
there would then be no place to back up the configuration information, and reliable 
maintenance of this information could become a significant problem. Replacing the disk 
would result in the loss of the information, A third reason is that it may not be possible to 
read a particular sector on all disks without knowing the disk type. An EEPROM or other 
storage medium other than the disk is required if the latter is true, because it would be 
unacceptable to ask the user the disk type on every hard boot. 

Contents of configuration EEPROM 

The configuration EEPROM should include the following kinds of information: 

• display type 

• keyboard type 

• rigid disk presence and type 

• floppy disk presence and type 
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• main memory size 

• virtual memory size 

• Ethernet presence 

• RS-232-C channel A and B device types and attributes 

• option board types and attributes, including PC emulation 

• booting options (default boot device, whether to run Boot Diagnostics) 

• memory lock mode (hardware or software) 

• address of last main memory parity error and count 

• list of bad main memory pages 

• checksum and its complement 
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This section discusses how rigid disk scavenging and formatting should be handled in 
relation to DOVE offline disk diagnostics. On the DANDELION, both physical volume 
scavenging and formatting were functions built into the offline disk diagnostics. For 
DOVE, the proposal is to package scavenging and formatting in a separate boot file from 
the full offline rigid disk diagnostics. This should make it possible to release new offline 
disk diagnostics only when the diagnostics themselves change, not when scavenging or 
formatting changes. 

B.l Scavenging 

DANDELION offline disk diagnostics include the ability to run the Pilot physical volume 
(PV) scavenger. The PV scavenger is a program that can restore damaged operating 
system data on the rigid disk. This data is required to be intact and valid in order to access 
the user data on the disk. Damage to this or other data on the disk can result from rigid 
disk hardware failures. Hence scavenging is a step that may be required to return a 
workstation to service after a rigid disk hardware failure has been repaired. 

One mode of operation of the PV scavenger is called "risky repair mode." Because of the 
risks of this "last-chance" scavenging mode, it is imperative that the disk hardware be 
healthy before the scavenger is run. Otherwise the scavenger can fail catastrophically. 
The only way to guarantee healthy hardware is to incorporate this mode of scavenging 
into the diagnostics, so that the diagnostics must be run immediately before invoking the 
PV scavenger in risky repair mode. 

One disadvantage of incorporating scavenging into the offline disk diagnostics is that new 
diagnostics must be released to the field with every release in which the scavenger 
changes. Field Service would prefer to release new diagnostics only when new diagnostic 
features are added or the hardware itself is changed. 

Another disadvantage is that the scavenging software takes up valuable main memory 
that could otherwise be used for additional diagnostic functions. The amount of memory 
involved is modest. 

For DOVE, a separate boot file will be produced for non-diagnostic ("utility") functions 
such as scavenging. This boot file will of necessity contain a subset of the offline disk 
diagnostics, so that the disk hardware can still be validated immediately prior to running 
the PV scavenger in risk repair mode. Other levels of scavenging from the hierarchy of 
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scavengers can also be packaged in this same boot file. Pilot's logical volume (LV) 
scavenger and page scavenger should be included. 

Separating scavenging from the main offline disk diagnostic boot file in this way will 
allow fewer field updates to offline disk diagnostics, as well as room in memory for a 
modest increase in diagnostic functions. 



B.2 Formatting 

DANDELION offline disk diagnostics also include the ability to run the Pilot disk 
formatter. The formatter program is used to initialize the disk with sector marks and 
header fields for each sector. It also records the disk sectors that are unuseable due to 
media flaws. This formatting is normally done once by manufacturing for each new disk, 
and never again. 

On rare occasions the formatting information on the disk is accidentally overwritten and 
invalidated, for instance as a result of a hardware failure. These rare instances require 
reformatting before the disk can be used again. The act of formatting a disk causes all 
prior ifnormation stored on that disk to be lost, so gratuitous formatting is to be avoided at 
all costs. Similar to scavenging, it is important that the disk hardware be completely 
healthy before formatting a disk. Hence disk formatting was included in the 
DANDELION offline disk diagnostics boot file. 

For DOVE, the formatting function will be included in the disk utility boot file, for the 
same reasons that scavenging has also been moved to this new boot file. 
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D.l Introduction 

This section describes the DOVE strategy for minimizing data loss on the rigid and floppy 
disk drives during power cycling of the machine. The power cycling will occur when the 
user or service person turns the machine off and on, or when power to the building in 
which the machine is installed is lost. The latter case is of a random nature, and thus 
precautions that could be taken in the former case cannot be used. 

What is the problem? When power is lost to the machine, a point is reached when the 
logical elements are no longer operating in their normal operating regions. If the machine 
is not carefully designed, the power loss couWcause unwanted write operations on the 
disk, thus damaging the data on the device. This problem applies to both the rigid and 
floppy drives, although the impact of any loss is far more serious on the rigid drive. 
Consequently, the amount of protection is much larger on the rigid drive. Similarly, if the 
circuits are not well behaved at power-up, similar destructive write actions could occur. 

The rest of this appendix describes what is provided in the DOVE design to minimize any 
data loss. It will be seen that there is a high degree of protection built into the DOVE 
system to minimize data loss on the magnetic media. It is not possible to totally eliminate 
the possibility of data loss; the attempt is to reduce the probability to an acceptable low 
level. In most cases, power cycling will cause no loss or damage of data. In a small 
percentage of the cases when power loss is unexpected, a single sector can be damaged. 
More than one sector will never be damaged. This single sector damage can, to some 
extent, be repaired by a scavenger program. 

D.2 Areas of protection 

There are several areas in the machine that need to be addressed to effect protection on the 
disk drives. In addition, software tools are needed to implement repair actions after some 
data loss has occured (so-called scavenging operations). This section discusses each of the 
following areas for both the rigid and floppy disk drives: power supply, disk controller, 
disk drive, and software. 
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D.2.1 Power supply 

When the AC power is lost to the system, the power supply has to immediately sense this 
occurrence and signal the lOP. In this way, the TOP can reset all its logic to an inactive 
state, so that the disk controllers will be well behaved during the power loss. The power 
supply generates a "power normal" signal indicating that all DC outputs are up and 
usable after the turn-on period, and also to indicate imminent loss of output during turn- 
off or AC input power failure .y After turn-on, power normal becomes logically active 
between 50 and 250 milliseconds after all voltages have exceeded 94% of their normal 
values. During AC turn-off or power loss, power normal will go logically inactive before 
any output decreases to 94% of the nominal value. (The power will actually disappear 
about 1 ms after power normxil becomes active.) The full cycle is repeated if a momentary 
power outage occurs. 

The power normal signal is provided to the lOP for its use. It provides the capability for the 
TOP to hold all controllers (in particular, the rigid disk and floppy controllers) in a reset 
state while the power is stabilizing at turn-on, and while the power is disappearing during 
turn-off. No further actions can occur during this reset state. An interesting situation is 
when there is actual disk-write activity as the power is being turned off. In this situation, 
it is impossible to prevent some data loss. The power normal signal allows this data loss to 
be minimized to one sector only (see below). 

D.2.2 Disk controller 

As mentioned above, when the controller is reset^by the system reset signal, no controller 
activity can occur. All control signals are in their inactive states. In the case of the disk 
controllers, the most critical signal is the WriteGate signal. Disk write operations can 
only occur when this signal is active. Resetting the system will stop all controller activity, 
and thus the WriteGate signal will not be activated. More importantly, the system reset 
signal gates the WriteGate signals directly. This ensures that the WriteGate signal is 
immediately (within 50 ns) aborted when the system reset becomes active. Thus, if 
WriteGate was active when the power loss occurred, the write operation will be aborted 
and the data loss minimized to the particular sector being written. The usual effect will be 
that the sector will have an invalid CRC which will need to be repaired by a scavenger (see 
below). This applies to both the rigid disk and floppy disk controllers. Note that in the case 
of the rigid disk, the sector damage could be in the label or data field, or both. (If the drive 
was being formatted, damage could occur to the header; but there is no user information 
on the track, and recovery can be effected by reformatting.) 

D.2.3 Disk drive 

The disk drives have additional protection built into them to prevent spurious writes 
during power up and power down. The DOVE Rigid Disk Drive Specification states that 
"Power ON/OFF sequencing of the DC power supplies shall not impact data integrity of 
the recorded information." The drives usually implement this by internally disabling the 
WriteGate signal to the drive when the DC power starts dropping. The Quantum drives 
internally disable WriteGate when the +6V drops 10% of its nominal value, and/or the 
+ 12V drops 20%. Note that this internal disabling of the WriteGate signal is over and 
above the controller disable. 
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In addition, the Quantum and Micropolis drives retract the heads to a landing area after 
power loss. The Seagate drive does not retract the heads or have a landing area, but has a 
dynamic brake to quickly bring the spindle to a stop. Other drives have a landing zone, but 
require software to move the heads there before power down. Note that it is still possible to 
damage the sector on which a write operation had started at time of the power outage. 

There is no internal drive protection on the floppy disk drives. Reliance is placed on the 
controller protection. (Floppies can also be individually write-protected.) 

On power-up, the rigid drives internally disable the WriteGate signal until the drives 
become ready. At this point, the DC power is guaranteed to be stable. 

D.2.4 Software 

There is no software to actually prevent spurious writing on the disks. The software 
discussed here is intended to repair the damage which occurs in the infrequent occasions 
that a sector is lost, as described above. These software tools are called scavengers, and 
their purpose is to rebuild the disk data structures. The full discussion of scavengers is 
beyond the scope of this section, but the particular operation with regard to repairing the 
bad sectors above will be described. 



A scavenger can rewrite these bad sectors and repair the invalid CRC. The data that was 
intended for the end of the sector cannot, of course, be rewritten, but the sector once more 
becomes a readable sector. Certain critical sectors on the rigid disk volume, such as the 
Physical Volume Root page, is redundantly written on the volume. The scavenger will 
repair such a damaged sector by retrieving the~irfformation from the redundant copy of 
that particular sector. Other sectors are handled differently depending upon whether the 
file with the bad sector is a Star file or a Tajo file. The current Star scavenger (File Check) 
does not attempt to repair the file that contains the bad sector. It actually deletes the 
entire file from the desktop. It is not known whether future File Check programs will 
improve on this. The Tajo scavenger will leave the rest of the file intact, and all that is lost 
is the part of the sector that was not written. If the damage occurred in a code sector, then 
full recovery can be achieved by reinstalling the software. 

Currently, no floppy scavenger exists. Thus, it is not known what level of repair will be 
provided in the future. 
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E.l Scope 

This plan defines the procedures to be followed during the DOVE workstation diagnostic 
validation. This documentation will include only electronic faults on subsystems unique to 
the DOVE workstation. 

E.2 Objectives and criteria 

This test has two primary objectives, Mean Time To Repair (MTTR) and Probability of 
Automatic Diagnosis (PAD). The diagnostic validation testing will cover the DOVE 
workstation including controllers, pheripherals, and Xerox offered options at the time of 
testing. 

E.2.1 MTTR 

The DOVE workstation is required to meet an MTTR average of not more than fifteen 
minutes for a single system failure in 99.8 per cent of the cases and shall not exceed 45 
minutes. MTTR includes diagnostic, removal of covers, removal and replacement of the 
failed FRU, verification of repair, and replacement of covers. It does not include other 
times which may be associated with a service call such as administrative time, parts 
procurement time, operator training, etc. 

E.2.2 PAD 

The DOVE workstation is required to meet the PAD to repair with a single FRU eighty 
percent of the time, two FRUs fifteen percent of the time, and three or more FRUs 4.9 
percent of the time. It is estimated that the system will be nnn rrpiir"^^"^ 0.1 percent of 
the time. IV\«^ ^W^nASSt 

E.3 System requirements 

One system will be required. Two sets of fully socketed PWAs are required to facilitate IC 
fault insertion. 
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E.4 Test requirements 



E.4. 1 Pre-test requirements 

When the system is received for testing, the following steps will be taken. 

• Functional verification of system operation with the standard PW As. 

• Functional verification of system operation with the spare PWAs. 
Software must be available to do Mesa level applications as well as diagnostics. 

All necessary tools, spares, and documentation must be in the test lab prior to test start. 



E.4.2 Functional responsibility 
E.4.2.1 Engineering 

Provide manpower and the basic test system of IMO configuration. No configuration 
changes will be permitted after the test has started. 

Two sets of socketed PWAs should be provided by Development Engineering. The original 
PWAs will be used as spares for replacement of the indicated failing FRU. 

The diagnostic implementors must supply an error code dictionary and pertinent data to 
Engineering for review prior to the start of test. 

E.4.2.2 Service 

Service shall provide service documentation where applicable. A Service test observer is 
optional. 

E.4.3 Test philosophy 

The testing intent is to measure the maintainability parameters which are exclusively or 
predominantly a function of system design. Service response time, logistics time, etc., are 
not pertinent to this demonstration. A field simulation will be maintained only to the 
extent necessary to ensure valid measurements of engineering maintainability 
parameters. 

The testing of an inserted fault is scored as a success or failure depending on whether or 
not the fault is properly diagnosed. The fault code must indicate the FRU, or if there are 
multiple FRUs, then the code should indicate the probability of each of the FRUs. If the 
tests find the failed fault, and the code predicates the failed FRU or FRUs, the test is 
scored as a success; if not, it is scored as a failure. Repair times and the faulty parts will be 
recorded. All parts used and all steps performed must be recorded. 

E.4.4 Test schedule 

The diagnostic validation will be run in three phases. The first phase will test prototype 
hardware, the second phase will test preproduction hardware, and the third phase will test 
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IMO hardware. The first two phases will be used for pinpointing shortcomings in the 
hardware and software so corrections to the hardware and software can be made for IMO. 
Failure to meet MTTR and PAD is not critical for the first two phases, but it is required 
that MTTR and PAD be met for the IMO test phase. 

At the conclusion of each phase of testing, Engineering will publish a report stating 
whether the present phase of testing has demonstrated that MTTR and PAD have 
exceeded the goals by a significant margin, met the goals, or have not met the goals. A 
report stating that the present phase of testing has not met the goals must include a plan 
to correct the shortcomings in hardware and/or software. 

E.4.5 Test details 

E.4.5.1 System verification 

Prior to inserting a fault, proper system operation will be verified to ensure that only a 
■ single fault is present at any given time. The required verification will include: 

• Boot Diagnostic 

• Mesa level software applications 

- E.4.5.2 Fault selection 

A random number technique will be used to "select a single fault from the fault list 
developed by Engineering and Service. The list must contain sufficient faults to provide 
the required sample of 300 faults with allowance for invalidations. The selection process is 
controlled so that frequencies reflect the anticipated reliability levels. The number of 
faults inserted in each subsystem is proportional to the probability of a fault occurring in 
that subsystem. For example, if 300 faults are inserted in the system, and the probability 
of failure in the subsystem being tested is 10 percent, then 30 faults will be inserted in 
that subsystem. 

E.4.5.3 Fault insertion 

The selected fault will be inserted in the system by the engineering test group. In the case 
of socketed PWAs,-a device lead may be bent or cut to induce the fault. Care will be taken 
to ensure the presence of a hard fault. Other techniques such as disconnecting wires, 
adding insulators, etc., will be used as required to generate the desired faults. 

E.4.5.4 Fault verification 

Once the fault has been inserted, the system verification will be reported to ensure that a 
fault symptom is present. If no symptom is displayed, the original configuration will be 
restored and a new fault selected. If there is reason to believe that the symptom displayed 
is not due to the inserted fault, the original configuration will be restored and the system 
reverified before proceeding. Failure of the diagnostics to detect an inserted fault will be 
scored on the data sheet as not diagnosable. 
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If the system fails the verification but the PSR has repaired the inserted fault, it will be 
assumed that a second fault occurred after the PSR completed his task. Therefore, this 
fault would be recorded as valid data. 

If the system passes the verification but the PSR has not repaired the inserted fault, the 
data point will be considered invalid and marked invalid. 

E.4.5.9 System restoration , 

The system will then be restored to the original configuration and steps E.4.5.1 through 
E. 4.5.9 repeated until the 300 samples required have been obtained. 

E.4.6 Invalid data 

Data will be invalidated only if a second fault is determined to be present. 

E.4.7 Test report 

A final report will be issued no later than two weeks after test completion. The report will 
include all data as well as any pertinent observations from the test. 
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F.l E2PR0M 

Presently there are two options for the E^PROM configuration control chip. The one that 
is chosen will determine what is in the chip and how it is used. There is a need for 
configuration control, bad memory management, and bad disk page logging in the 
E2PR0M. The order in which they are mentioned is their order of priority. All data in the 
E2PR0M should be backed up on the rigid disk. 

F.2 Configuration control 

There are 10 items that need to be described in tbeE2PR0M. Most of the subsystems need 
only a couple of bits to describe the known variations, but for programming reasons it is 
best to use words, bytes, or nibble bit groups. If the 2k X 8 E2PR0M is used, the byte 
method is most practical. In the case of 64 X 16, the method used will be mandated by the 
amount of information that is needed to be stored. Some of the things that need to be 
placed in the E2PR0M are default boot devices (rigid disk, Ethernet, RS-232, and floppy 
disk), Ethernet configurations (Ethernet present, standard Ethernet, optical, and cheaper 
net), displays (15-inch, 17-inch, 19-inch, and color), keyboard types (English, German, 
French, Swedish, Norwegian, Danish, Italian, Finnish, Japanese, and Chinese), floppy 
disks (present and type), memory sizes, RS-232-C-DTE (set up and usage), RS-232-C-DCE 
(set up and usage), option slots (set up and usage), and E2Prom checksum. 

F.3 Bad memory management 

It can be shown that 60 percent of the memory service calls can be saved by mapping out 
bad memory. In another 20 percent of the failures the problem can be corrected by 
mapping out 128 pages. It should be noted that mapping out 128 pages would slow down 
the system considerably in the basic workstation configuration but would have little effect 
on a four megabyte system. Mapping out 128 pages is not acceptable for the long run but 
will allow the user to operate until a service call can be made. The customer who performs 
his own service can elect to fix the mapped out memory or leave it. 

Another aspect of bad memory management is trapping and logging of parity memory 
crashes. This would require pilot to trap and record the last page in memory accessed 
when a parity error occurs. Soft errors are random and some are repeatable; the repeatable 
soft errors will cause frustration especially when the system gets up to four megabytes. To 
make memory mapping completely functional and effective, pilot must start using none 
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